🏯 fix: Guard Worker Credentials From Local Accounts - #112

Follow-up to #107, now merged. That PR fixed a reproducible defect — chmod silently no-ops on WSL2 DrvFs, so the worker's Ed25519 private key was written world-readable while pairing reported success. This one is different in kind, and needs its own decision.

The question this PR is really asking

Is another local account on the same host in scope for BYOM?

Everything here defends that threat. BYOM's stated model is a worker on the user's own machine or VM, with the trusted worker outside the sandbox and the sandboxed command as the adversary. Under that model none of this is needed. Under a shared or managed host, all of it is.

It is separate because these checks buy that defence by trading deployment flexibility, and that trade should be made deliberately rather than accumulated under review pressure. Two of them can refuse setups that work today:

• Container ownership refuses an identity in a directory owned by a provisioning or service account — plausible in containerized deployments.
• Default-workspace ownership refuses a pre-provisioned workspace directory owned by another account.

If the answer to the question above is "no", most of this should be dropped rather than merged. I would rather ask than assume.

What it adds

Ownership. Mode bits do not establish trust: a 0600 file owned by another account is unreadable by others yet fully rewritable by its owner, who then controls the credential the worker loads — or, for a quarantine marker, can delete it and let mutations resume. The containing directory is judged the same way, since an owner lacking write bits today can grant them tomorrow. Root counts as the trust root. --default-workspace is application-owned by contract, so a pre-existing one under another account is refused too.

Containers. A 0600 file in a directory others can write can be unlinked and replaced. Publishing goes through rename, which replaces the named entry, so the write path judges the entry's directory; reading follows the link, so both ends are judged. The sticky bit counts as protection, keeping /tmp-style parents usable.

Pairing preflight. pair redeemed the one-time code before the destination was known usable, so an unusable path cost the code and left an orphaned remote pairing — reproduced with --identity <existing dir>, which surfaced a raw EISDIR after the code was spent. The destination is now validated and then claimed, so another account cannot take the name while the request is in flight. The claim records its inode and is released only if the file is still that inode and still empty, so a concurrent pairing that published a real identity over the name is never destroyed by another invocation's unwind.

Verification

Measured against real paths before committing to the rule: ~ is 0750 and ~/.config 0751 here, both accepted; /tmp at 1777 is accepted via the sticky bit. A naive & 0o077 ancestor check would have rejected the default identity path, which is why the rule is write-bits-plus-sticky rather than mode-wide.

41/41 focused tests (storage, cli, workspace-cli — the only dependents of the changed functions). tsc --noEmit clean.

Known gaps, left explicit rather than half-done

• Only the immediate container is checked. A writable ancestor could still rename a private directory out from under the worker.
• Bind-mounted destinations still fail at rename with EBUSY. Every detection I found either false-positives on btrfs subvolumes (st_dev) or races (/proc/mounts), and a test-rename would clobber the file it protects.
• macOS extended ACLs and Windows ACLs are both outside what a mode check can see. Node exposes no ACL API, so this needs a subprocess validated on a host that has those platforms — neither is available here, and an unverified subprocess in the credential path is worse than a stated limit.

The sticky-plus-foreign-owner reject path cannot be exercised without root, so the test there covers the regression instead: an owned file in a sticky directory stays replaceable.